Bisher war CrowdSec unser verlässlicher Türsteher: Es hat IPs erkannt, die sich danebenbenehmen (z.B. durch zu viele fehlgeschlagene Logins), und diese dann via Bouncer auf Netzwerkebene blockiert. Das ist effektiv, hat aber eine Schwachstelle: Es ist “nur” Log-Parsing.
CrowdSec musste bisher warten, bis eine Anwendung (bei uns Traefik) einen Fehler in eine Logdatei schreibt, um darauf zu reagieren. Doch was passiert, wenn der Angriff gar keinen Fehler im Log erzeugt, sondern eine Sicherheitslücke in der Anwendung selbst ausnutzt (wie bei Log4Shell oder SQL-Injections)?
| Datum | Änderungen |
|---|---|
| 04.03.2026 | Erstellung dieser Anleitung |
| 20.03.2026 | Doppelte Inhalte zur Traefik Anleitung entfernt, Kapitel 6 angepasst. CHANGELOG |
1. Was ist CrowdSec AppSec?
Mit der Einführung der AppSec-Komponente verwandelt sich CrowdSec von einem reinen Log-Parser in eine vollwertige Web Application Firewall (WAF).
Anstatt nur Logs zu lesen, klinkt sich CrowdSec jetzt direkt in den Datenstrom ein. In unserem Fall sitzt es als Middleware direkt im Traefik Proxy. Jede HTTP-Anfrage wird analysiert, bevor sie überhaupt deine Docker-Container erreicht.
AppSec prüft dabei auf Muster, die wir als “Low Reputation” kennen:
- SQL-Injections (SQLi)
- Cross-Site Scripting (XSS)
- Remote Code Execution (RCE)
- Bekannte Angriffsvektoren (User-Agent Scans, Path Traversal)
2. Der Vorteil: Virtuelles Patchen
Der größte Vorteil ist das sogenannte Virtual Patching. Wenn morgen eine kritische Sicherheitslücke in einer deiner Apps bekannt wird, musst du nicht sofort Panik schieben und Updates einspielen (was man natürlich trotzdem tun sollte). CrowdSec kann die spezifischen Angriffsmuster auf diese Lücke oft schon blockieren, bevor der Patch überhaupt installiert ist. Es kauft dir wertvolle Zeit.
Grundlage dieser Anleitung ist die Anleitung von @psycho0verload zu unserer Traefik CrowdSec Combo (Kapitel 13). Ihr müsst dies bereits erledigt haben, damit ihr mit dieser Anleitung weitermachen könnt.
3. Wichtiger Hinweis für dieses Setup – Nur für Experten
Die hier gezeigte Konfiguration mit CrowdSec AppSec und CRS (Core Rule Sets) bietet eine sehr hohe Sicherheit, ist aber kein Setup für Anfänger!
Die strikten Regeln verursachen in der Praxis unweigerlich False Positives. Ohne tiefgreifendes Verständnis und manuelles Finetuning werden Standardanwendungen wie Nextcloud oder WordPress nicht mehr reibungslos funktionieren. Dies führt ebenfalls dazu, dass ihr auf eurem eigenen Server gebannt werdet.
Setzt diese Anleitung nur um, wenn ihr bereit seid, Logfiles zu analysieren und individuelle Ausnahmeregeln (Exclusions) für eure Dienste zu schreiben. Wer ein einfaches „Install-and-Forget“-System sucht, sollte auf die aggressiven CRS-Regeln verzichten. Diese Anleitung wird zu 100% dafür sorgen, dass initial eure Dienste / Anwendungen irgendwelche Fehler verursachen und nicht mehr korrekt funktionieren.
4. Grundvoraussetzungen
Bei diesem Inhalt handelt es sich um exklusiven Content für Community Plus Mitglieder und Supporter.
Bitte logge dich mit deinem Account ein um den Inhalt zu sehen.
Nun starten wir das Skript:
/opt/containers/traefik-crowdsec-stack/crowdsec-test.shHier solltet ihr nun folgendes sehen, wenn alles korrekt läuft:
==============================================
CrowdSec AppSec (WAF) Test-Skript
==============================================
Bitte gib deine Traefik-Domain ein (z.B. traefik.deinedomain.de): xxxx.de
Ziel-URL festgelegt auf: https://xxxx.de
Bereinige Altlasten (Lösche alle bestehenden Bans)...
[1/4] Zeige initiale AppSec-Metriken...
+-------------------------------------+
| Appsec Metrics |
+---------------+-----------+---------+
| Appsec Engine | Processed | Blocked |
+---------------+-----------+---------+
| 0.0.0.0:7422/ | 34 | 2 |
+---------------+-----------+---------+
+---------------------------------------------+
| Appsec '0.0.0.0:7422/' Rules Metrics |
+---------------------------------+-----------+
| Rule ID | Triggered |
+---------------------------------+-----------+
| 901340 | 2 |
| 930130 | 2 |
| 980170 | 2 |
| crowdsecurity/vpatch-env-access | 1 |
| crowdsecurity/vpatch-git-config | 1 |
+---------------------------------+-----------+
[2/4] Führe simulierte Angriffe gegen https://fatalplayers.de aus...
--- Standard Web-Angriffe (OWASP CRS IDs) ---
-> Teste SQL-Injection (SQLi)... Blockiert (HTTP Code: 403) ✓
-> Teste Cross-Site Scripting (XSS)... Blockiert (HTTP Code: 403) ✓
-> Teste Local File Inclusion (LFI)... Blockiert (HTTP Code: 403) ✓
--- Generische Web-Angriffe (Namen-IDs) ---
-> Teste WP Uploads PHP (generic-wordpress-uploads-php)... Blockiert (HTTP Code: 403) ✓
-> Teste WP Uploads Listing (generic-wordpress-uploads-listing)... Blockiert (HTTP Code: 403) ✓
--- Virtual Patching (CVEs & Exposures) ---
-> Teste PHP CGI RCE (CVE-2024-4577)... Blockiert (HTTP Code: 403) ✓
-> Teste Exposed .env Datei (vpatch-env-access)... Blockiert (HTTP Code: 403) ✓
-> Teste Exposed Git Verzeichnis (vpatch-git-config)... Blockiert (HTTP Code: 403) ✓
[3/4] Warte 4 Sekunden auf die Verarbeitung durch CrowdSec...
[4/4] Zeige aktualisierte AppSec-Metriken...
+-------------------------------------+
| Appsec Metrics |
+---------------+-----------+---------+
| Appsec Engine | Processed | Blocked |
+---------------+-----------+---------+
| 0.0.0.0:7422/ | 42 | 10 |
+---------------+-----------+---------+
+-------------------------------------------------------------+
| Appsec '0.0.0.0:7422/' Rules Metrics |
+-------------------------------------------------+-----------+
| Rule ID | Triggered |
+-------------------------------------------------+-----------+
| 901340 | 10 |
| 930100 | 1 |
| 930110 | 1 |
| 930120 | 1 |
| 930130 | 4 |
| 932160 | 1 |
| 941100 | 1 |
| 941110 | 1 |
| 941160 | 1 |
| 941390 | 1 |
| 942100 | 1 |
| 949110 | 3 |
| 980170 | 7 |
| crowdsecurity/generic-wordpress-uploads-listing | 1 |
| crowdsecurity/generic-wordpress-uploads-php | 1 |
| crowdsecurity/vpatch-CVE-2024-4577 | 1 |
| crowdsecurity/vpatch-env-access | 2 |
| crowdsecurity/vpatch-git-config | 2 |
+-------------------------------------------------+-----------+
==============================================
Test beendet!
Die Metriken ('Processed' und 'Blocked') sollten nun exakt um 8 gestiegen sein.Code-Sprache: PHP (php)
Hallo,
ich habe eine Verständnisfrage. Gibt es Anwendungen die so programmiert sind dass ich mein System öffnen muss sodass der Live test nicht zu 100% erfolgreich ist. Ich habe als Beispiel Wallebagger. Das bekomme ich als alerts list.
Key | Value |
+—————+————————————————————–+
| ja4h | po11nn17de00_c24cd69737ef_000000000000_000000000000 |
| matched_zones | ARGS.json.content |
| method | POST |
| msg | XSS Attack Detected via libinjection |
| msg | XSS Filter – Category 1: Script Tag Vector |
| msg | NoScript XSS InjectionChecker: HTML Injection |
| msg | Javascript method detected |
| name | native_rule:941100 |
| name | native_rule:941110 |
| name | native_rule:941160 |
| name | native_rule:941390 |
| target_uri | /api/entries.json
Wenn ich die 4 native_rule in die Regelliste aufnehmen erhalten ich im Live Test
-> Teste Cross-Site Scripting (XSS)… Durchgelassen (HTTP Code: 401) ✗ – WAF hat nicht gegriffen!
Gibt es da überhaupt eine Lösung. Vielen Dank
Gruß Andreas